Techniques for Safety Critical Software Development

Although the dreams of artificial intelligence have not been realized (despite the recent success of IBM in chess), it is apparent that software control of machines is quickly permeating our lives in many ways – some seen, some hidden. NASA is clearly dependent on computers to fly the space shuttle or to run the planned space station. Many commercial and military aircraft alike require computer systems to maintain flight and navigate. Power plants that produce electricity from nuclear fuel require software to monitor and control system conditions. Robot control of manufacturing machines and assembly lines implies embedded software. These and other application area require software systems that not only work correctly, but also satisfy safety concerns. A growing number of software systems can now be labeled safety critical. Peter Neumann writes [9, p.3]: Increasingly, we depend on computer systems to behave acceptably in applications with extremely critical requirements, by which we mean that the failure of systems to meet their requirements may result in serious consequences...We explore various inherent limitations both of the technology and of the people who interact with it. Certain limitations can be overcome – albeit only with significant effort. We must strive to promote the development and systematic use of techniques that can help us to identify the intrinsic limitations, and to reduce those that are not intrinsic—for example, through better systems and better operational practices. Examples of catastrophic failures of software systems are not difficult to find. The column “Risks to the Public” [11] in Software Engineering Notes describes many specific examples of risks to the public caused by software failures. The Therac-25 accidents [7] are some of the most widely reported examples of computer system failure. In the software engineering field, there is a wide recognition of the importance of accurate requirements. This is most apparent among researchers in formal methods of specification. It is obvious that a safe system will generally not result from inaccurate, incomplete, or inconsistent specifications. The last decade has seen